No demasiado seco: cómo exhibir los SDK manteniendo el código de la aplicación simple

Ingenieros, imaginen este escenario. Su colega del equipo de producto le envía un mensaje de Slack un lunes por la mañana. "¡Oye!" Ella dice: "Acabamos de obtener un nuevo proveedor a través de adquisiciones". Las palabras comienzan a hacer un nudo en tu estómago, como si tu pareja te acabara de enviar un mensaje de texto diciendo "tenemos que hablar".

En la parte inferior de la ventana de chat, Slack le dice que su colega está escribiendo... . y el nudo se aprieta. “Es una plataforma de análisis que nos dará más visibilidad sobre los recorridos de los usuarios”, dice su mensaje. “¿Crees que podamos tenerlo integrado en la Web, iOS y Android para fin de mes?”

Sabes que tu colega solo está haciendo su trabajo. Después de todo, la gente del producto necesita ver dónde se atascan los usuarios en el nuevo flujo de incorporación, y esta herramienta debería ayudarlos.

Pero temes lo que esto significa para ti y tus compañeros desarrolladores. La última vez que tuvo que implementar un SDK de proveedor, fue como salir de una habitación abarrotada con los ojos vendados.

Te estremeces ante la idea de tener que volver a armar el modelo mental detrás de una nueva API y vincular este sistema a tu propio código base sin romper nada, mientras piensas que todavía tengo que construir esa nueva característica, y esta integración está entrando mi manera.

Esta situación es una con la que los ingenieros de mParticle están íntimamente familiarizados. Si bien en estos días nuestros desarrolladores crean SDK en lugar de implementarlos, muchos de nuestros ingenieros saben lo que es estar del otro lado de la mesa cantando el "New SDK Blues".

Es esta experiencia de primera mano lo que nos llevó a hacer nuestra última inversión en la experiencia de desarrollador de mParticle: aplicaciones de comercio electrónico de muestra completamente funcionales para Web , iOS , y Androide , implementado de principio a fin con nuestros SDK.

Estas aplicaciones le brindan un campo de juego para experimentar con nuestro SDK y aprender cómo funciona la recopilación de eventos con mParticle. Destacan ejemplos prácticos de nuestros eventos implementados en acciones comunes de los usuarios, como vistas de página, personalizaciones de productos, botones para agregar/eliminar del carrito y botones de pago, entre otros.

En muchos casos, es posible que pueda copiar estos eventos directamente en su propia aplicación y solo realizar ligeras modificaciones para satisfacer las necesidades de su caso de uso específico.

En el siguiente video, Alex Sapountzis y Peter Jenkins, los ingenieros de mParticle que dirigieron el desarrollo de aplicaciones de muestra para la Web y iOS, respectivamente, analizan sus propias experiencias al implementar SDK de proveedores y por qué desarrollaron las aplicaciones de muestra.

https://www.youtube.com/watch?v=1hYc9qalrXQ

“Queremos brindarle rápidamente un mapa mental de lo que sucede tanto en su aplicación como en nuestro sistema cuando implementa mParticle, sin que tenga que pasar por muchas pruebas y errores”, dice Matt Bernier, gerente sénior de productos de experiencia de desarrollador en mpartícula.

“Dado que estas aplicaciones le muestran nuestros SDK ejecutándose exactamente en el contexto que está buscando, no hay que hacer conjeturas. Esto significa que puede finalizar su implementación y pasar al siguiente proyecto más rápidamente”.

Mirando bajo el capó de las aplicaciones de muestra

Si es cliente de mParticle, puede ver estas aplicaciones en acción y consultar el código directamente a medida que aprende más sobre nuestro proceso de creación. Así es como puede ejecutar la aplicación localmente:

Nota: necesitará acceso a un espacio de trabajo de mParticle para generar una clave de API.

1. Clonar el repositorio de aplicaciones de muestra .
2. Instale las dependencias del paquete mediante npm install.
3. Vaya a Configuración > Entradas en su espacio de trabajo de mParticle.
4. Seleccione la plataforma web y genere/copie su clave API.
5. En la raíz de este proyecto, cambie el nombre de .env.sample a .env.
6. Actualice la variable de entorno REACT_APP_MPARTICLE_API_KEY con su clave API web de mParticle.
7. Ejecute el proyecto usando npm start.

¿No es actualmente un cliente de mParticle? Nuestro Programa Acelerador es una oportunidad para que las nuevas empresas calificadas reciban hasta un año de acceso gratuito a mParticle.

No demasiado seco: cómo mostramos nuestro SDK manteniendo el código de la aplicación simple

Por encima de todo, el equipo de aplicaciones de muestra quería que estos productos sirvieran como herramientas de enseñanza para que los ingenieros aprendieran nuestros SDK y comprendieran las mejores prácticas para implementar la recopilación de eventos con mParticle.

Este objetivo informó muchas de las opciones técnicas detrás de las aplicaciones de muestra, desde las herramientas y los marcos utilizados para construirlas, hasta las convenciones de codificación utilizadas en los proyectos.

La relación fue la razón principal por la que Alex Sapountzis decidió usar React como el marco en el que construir la aplicación web de muestra. reaccionar es el marco frontend más popular en el mundo, y se utiliza para crear aplicaciones que van desde sitios de comercio electrónico hasta plataformas de transmisión.

Por lo tanto, es una apuesta segura que la mayoría de los desarrolladores web que implementarían mParticle Web SDK no tendrían que aprender React antes de poder obtener valor de esta aplicación de muestra.

Cuando llegó el momento de decidir qué patrones de diseño de React usar, Alex trató de lograr un equilibrio favoreciendo características 'incorporadas' relativamente nuevas, como React Hooks y Context Providers versus Redux, una biblioteca de terceros que es ampliamente utilizada. arquitectura estándar conocida, pero puede ser muy abrumador y complejo para, en última instancia, ofrecer una experiencia de aprendizaje más clara al usuario.

Por ejemplo, usando ganchos personalizados ha sido una tendencia dentro de la comunidad React durante bastante tiempo. El uso de estos implica la creación de sus propias funciones que aprovechan los ganchos comunes de React con el fin de compartir la lógica con estado entre los componentes.

Alex sintió que el uso de este enfoque en las aplicaciones de muestra habría impedido comprender cómo funciona nuestro SDK y, por esta razón, optó por seguir usando ganchos de vainilla como useEffect.

"Si estuviera creando esto como un paquete que alguien usaría en su proyecto, podría haber hecho las cosas un poco diferentes", dice Alex, "pero como se trata de una herramienta educativa, no quería que nadie tuviera que preocuparse por qué está haciendo React: quería que vieran qué está haciendo mParticle en una aplicación React”.

Al explorar los componentes de la aplicación web, verá varios ejemplos en los que useEffect se usa para recopilar los atributos que se reenviarán con eventos mParticle y activar los eventos mismos. Aquí hay uno de esos usos de useEffect en el componente ProductDetailPage :

 useEffect(() => { // Generates a Product View Detail Event to signal that a customer // viewed the product details, potentially leading to an 'Add to Cart' Event if (product) { // Generate an mParticle Product Object before sending any eCommerce Events const mParticleProduct: mParticle.Product = getMPProduct(product); // Fire a single eCommerce Product View Detail Event for this product page mParticle.eCommerce.logProductAction( mParticle.ProductActionType.ViewDetail, mParticleProduct, ); } // If you re-render and the product changes, // this will re-fire a new Product View Detail Event }, [product]);

El uso del gancho Vanilla React en instancias como esta hace que sea mucho más fácil comprender el SDK de mParticle que si esta lógica estuviera empaquetada en funciones separadas a lo largo de diferentes módulos. Además, puede notar que esta es una muestra de código con muchos comentarios.

Los desarrolladores de la aplicación de muestra se tomaron el tiempo para comentar claramente el código relacionado con el uso de nuestro SDK, tanto donde se realizan las llamadas de eventos como en toda la lógica que admite la recopilación de eventos.

Aquí hay otro ejemplo del mismo componente que muestra cómo los comentarios ayudan a darle el contexto completo de cómo usar nuestro SDK en escenarios de la vida real, y no dejan nada a las conjeturas:

 // It is recommended to use mParticle.createProduct when using our // eCommerce logging functions to generate events so that you can // be sure to include all of our data points properly const getMPProduct = (_product: Product): mParticle.Product => { const { label, id, price } = _product; // When passing attributes into mParticle, it's best to not include // undefined or null values const attributes: mParticle.SDKEventAttrs = {}; if (color) { attributes.color = color; } if (size) { attributes.size = size; } // In this example we are not fulling handling multiple brands, // categories and other use cases for a fully fledged e-Commerce // application. As such, we are passing undefined for many of these // attributes to highlight cases where you want may need some // parameters but not all of them. return mParticle.eCommerce.createProduct( label, id, price, parseInt(quantity, 10), undefined, // Variant: used for single variants. // Use Custom ATtributes for multiple variants like // in this use case undefined, // Category undefined, // Brand undefined, // Position undefined, // Coupon Code attributes, ); };

https://www.youtube.com/watch?v=6zbW4X8Oyg0

Prueba interna de nuestros propios SDK y características y aprovechamiento de nuestros propios productos

Si bien el objetivo principal de estas aplicaciones de muestra es ayudar a nuestros clientes a implementar fácilmente nuestro SDK y obtener valor de sus datos, también hemos visto un gran valor interno en estas aplicaciones como un medio para probar y mejorar, o “perfilar”, nuestro propios SDK y funciones orientadas al cliente.

Caza de errores en la naturaleza de TypeScript

Por ejemplo, la creación de la aplicación web de muestra nos permitió descubrir algunos casos extremos que surgen al usar nuestro SDK web principal dentro de un proyecto React con TypeScript como un paquete npm.

En algunos casos, la interacción entre estas tres tecnologías particulares resultó en una condición de carrera en la que nuestro SDK no siempre se inicializaba cuando se llamaba a un evento.

Si bien nuestro SDK central ya contenía lógica para lidiar con esto, cierto código dentro de los paquetes de React rompió estos controles y provocó que ocurriera una cascada inusual. Después de notar este problema, Alex realizó una búsqueda de errores con el gurú de la API de JavaScript, Rob Ing. Los dos atravesaron el seguimiento de la pila, solucionaron el problema y lanzaron parches para nuestro SDK principal.

Uso de nuestras propias funciones de planificación de datos

Las inconsistencias en la etapa de recolección de datos son una de las mayores causas de problemas de calidad de datos más abajo en la tubería.

Las herramientas y funciones de planificación de datos de mParticle están diseñadas para ayudar a los ingenieros y otras partes interesadas en los datos a alinearse en un plan de datos, implementar este plan con precisión e identificar errores en tiempo real.

Cuando creamos estas aplicaciones de muestra, queríamos practicar lo que predicamos usando nuestras propias herramientas de planificación de datos para mantener la coherencia con la forma en que se nombran, estructuran y recopilan los eventos y atributos en estas tres plataformas.

Nuestros ingenieros y PM configuraron un espacio de trabajo de mParticle dedicado para el proyecto de aplicaciones de muestra y utilizaron nuestra interfaz de usuario para crear y generar planes de datos. Una vez que los eventos se implementaron en las tres aplicaciones y enviamos eventos desde los SDK a mParticle, usamos Live Stream para verificar si hay desalineaciones entre los datos recopilados y esperados, y los mensajes de error de Live Stream para rastrear fácilmente la fuente de los errores.

El uso de estas funciones hizo que el proceso de creación de planes de datos, implementación de la recopilación de eventos y garantía de la coherencia entre plataformas fuera mucho más fluido. Nuestras propias funciones de planificación de datos fueron de gran ayuda en la creación de las aplicaciones de muestra, y planeamos continuar usando las aplicaciones de muestra para probar y mejorar nuestras funciones de planificación de datos.

¿Qué depara el futuro?

Al reducir la curva de aprendizaje con nuestro SDK, acelerar el tiempo de implementación y disminuir el tiempo de valorización de sus datos, estas aplicaciones de muestra pueden brindar un valor de gran alcance a los equipos de ingeniería que trabajan con mParticle.

El hecho de que hayamos enviado nuestro MLP ("Minimum Loveable Project", un término que acuñó nuestro PM Matt Bernier) marca el comienzo, no el final, de nuestro trabajo para mejorar estos recursos.

"Creo que esto es definitivamente algo en lo que vamos a seguir invirtiendo y mejorando con el tiempo", dice Peter Jenkins, "desde agregar comentarios adicionales hasta mantenerlo siempre actualizado con los cambios que hacemos en el SDK".

Además, también tenemos la intención de continuar usando estas aplicaciones como un medio para probar y mejorar no solo nuestras funciones SDK y API, sino todo nuestro conjunto de productos y funciones.

En las próximas iteraciones de la aplicación de muestra web, por ejemplo, planeamos integrar nuestras herramientas para desarrolladores, incluidas tipo inteligente y pelusa . En otras palabras, estas aplicaciones de muestra serán, como dice Peter Jenkins, "una fuente perenne de documentación sobre cómo usar exactamente nuestro SDK que realmente puede ejecutar".

https://www.youtube.com/watch?v=Z02F77Yfs_E

Publicado anteriormente aquí.